The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Traditionally, it has been difficult to diagnose problems with paths in a packet-switched network, in which each of multiple network infrastructure elements (e.g., routers) makes forwarding decisions for network packets that traverse the paths. The approaches currently being used to determine whether a router correctly forwards packets provide for sending one or more network packets to the router and receiving from the router return packets that carry information indicating any problems. For example, one approach provides for using various Internet Control Message Protocol (ICMP) mechanisms, such as, for example, the tracert (trace route) utility provided on the Windows® family of operating systems. In general, the ICMP-based mechanisms provide for sending a control packet from a source to a destination and for monitoring ICMP messages in return network packets that are generated by any router(s) that cannot for whatever reason forward the control packet to the destination. One disadvantage of the ICMP-based mechanisms is that a network management station can trace the path from source A to destination B only if the network management station is on the same subnet as source A.
Another approach for diagnosing network path problems uses the source routing option provided by the various versions of the Internet Protocol (IP). The IP source routing option allows the originator of a network packet to specify what path through the network that packet will take and what path would be taken by any return packets. In this approach, a network packet with the IP source routing option is sent to a particular destination over a particular path; the information included in any return packets would be then inspected to diagnose any forwarding problems on that particular path. One disadvantage of this approach is that processing of network packets with the IP source routing option is disabled in the routers of most packet-switched networks because this option poses a security risk and because unique Reverse Path Forwarding (uRPF), which is used in secure networks, fails for network packets with that option.
A common disadvantage of the above approaches is that, while these approaches may identify a router that causes a problem on a particular network path, these approaches do not provide detailed enough information to determine exactly what in that router causes the problem. For example, these approaches cannot provide sufficient information about the forwarding decisions for packets that are forwarded by using Policy-Based Routing (PBR) and/or Multi-Topology Routing (MTR). When PBR and/or MTR are configured in a router, the router makes forwarding decisions not only on IP information but also based on information from protocols in the layers of the communication stack that are different than the network layer (e.g., data link layer, transport layer, application layer, etc). However, the above approaches for diagnosing network path problems can only provide information from network layer protocols (e.g., IP information) but cannot provide information from protocols at other communication stack layers.